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DETAILED ACTION 

This action is responsive to the Amendment/Arguments filed on January 27, 2009. Claims 1, 2, 
12, 13, 16-18, and 27-44 have been amended. Claims 50-53 have been added. Claims 1-53 are 
pending. 



Response to Arguments 

1. Applicant's arguments with respect to Claim Rejections under 35 U.S.C. 103(a) have 
been fully considered but they are not persuasive and/or are moot in view of the new ground(s) 
of rejection. 

As to Applicant's arguments with respect to Claims 1 and 27: 

a. Applicant alleges that the list of neighbor interfaces does not indicate status of at least 
two different protocols. 

Examiner respectfully disagrees. Comer (Figure 15.10 BGP Functionality and Message 
Types and 15.16 BGP KEEP ALIVE Message) provides a message including the status of at least 
two different protocols. The list of neighbor interfaces, as taught by Sandick (4.2 Parameters and 
B.l FLIP Advertisement Message), serves as data indicative of a state (up or down) and is in fact 
the purpose of the message. 



Claim Rejections - 35 USC §103 

2. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 
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(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 

3. Claims 1-15, 19-41, 45-49, 50, and 52 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Internetworking with TCP/IP to Comer and further in view of Internet-Draft 
Fast Liveness Protocol to Sandick et al. (hereinafter "Sandick") (IDS submitted on July 12, 
2004). 

4. As to Claims 1 and 27, Comer discloses for use with a node, a method and apparatus 
(referenced hereinafter as the method) comprising: 

a) accepting, using the node, status information from at least two different protocols 
(Comer; 15.10 BGP Functionality and Message Types and 15.16 BGP KEEPALIVE Message, 
discloses determining at a first node status information for both BGP and TCP protocols); 

b) composing, using the node, an aggregated message including the status information 
from the at least two different protocols [. ..] (Comer; Figure 15.10 BGP Functionality and 
Message Types and 15.16 BGP KEEPALIVE Message, discloses composing an aggregated 
keepalive message including the status information); and 

c) sending, using the node, the aggregated message towards a neighbor node (Comer; 
15.10 BGP Functionality and Message Types and 15.16 BGP KEEPALIVE Message, discloses 
sending the keepalive message to neighbor second node). 
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Comer does not explicitly disclose, however Sandick discloses including the status 
information from the at least two different protocols as data within the aggregated message 
(Sandick; 4.2 Parameters and B.l Flip Advertisement Message; list of neighbor interfaces as data 
in the message that indicates the status of the interfaces). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to modify status information and an aggregated message, as disclosed by Comer, to 
include explicitly indicating multiple statuses as data within the aggregated message, as 
disclosed by Sandick, in order to employ known methods of explicitly indicating status in a 
message. 

5. As to Claims 2 and 28, Comer and Sandick disclose each and every limitation of Claims 
1 and 27. Sandick further discloses: 

d) maintaining, using the node, a first timer for tracking a send time interval, wherein the 
acts of composing the aggregated message and sending the aggregated message are performed 
after expiration of the first timer (Sandick; 4.2 Parameters and 5.3 Finite State Machine for Hello 
Message Exchange, discloses maintaining a Hellolnterval timer to determine how often FLIP 
hello messages should be sent); and 

e) restarting, using the node, the first timer after the aggregated message is sent (Sandick; 
4.2 Parameters and 5.3 Finite state machine for Hello Message Exchange, discloses restarting the 
timer after the message is sent). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to modify composing and sending an aggregated message, as disclosed by Comer, to 
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include a send time interval and associated first timer, as disclosed by Sandick, in order to 
facilitate neighbor or peer protocol failure detection (Sandick; Abstract and 4.2 Parameters). 

6. As to Claims 3 and 29, Comer and Sandick disclose each and every limitation of Claims 
1 and 27. Sandick further discloses wherein the aggregated message further includes a dead 
time interval, and wherein the send time interval is less than the dead time interval (Sandick; 4.2 
Parameters and 5.3 Finite State Machine for Hello Message Exchange, discloses a 
PeerDeadlnterval, included in a FLIP Advertisement, that is larger than the Hellolnterval and 
that indicates how long a device should wait from the last Hello before declaring a neighbor 
failure). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to modify an aggregated message, as disclosed by Comer, to include a dead time 
interval which is greater than the send time interval, as disclosed by Sandick, in order to facilitate 
neighbor or peer protocol failure detection (Sandick; Abstract and 4.2 Parameters). 

7. As to Claims 4 and 30, Comer and Sandick disclose each and every limitation of Claims 

1 and 27. Sandick further discloses discloses wherein the aggregated message further includes a 
dead time interval, and wherein the send time interval is no more than one third of the dead time 
interval (Sandick; 4.2 Parameters and 5.3 Finite State Machine for Hello Message Exchange, 
discloses a PeerDeadlnterval, included in the FLIP Advertisement, that is at least 3 times the 
value of the Hellolnterval). 
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It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to modify an aggregated message, as disclosed by Comer, to include a dead time 
interval which is greater than 3 times the send time interval, as disclosed by Sandick, in order to 
facilitate neighbor or peer protocol failure detection and prevent erroneous declaration of a peer 
protocol failure in a situation where a message was lost in transmission (Sandick; Abstract and 
4.2 Parameters). 

8. As to Claims 5 and 31, Comer and Sandick disclose each and every limitation of Claims 
1 and 27. Sandick further discloses wherein the send time interval is less than one second 
(Sandick; 7.2 Hellolnterval, discloses the Hellolnterval default value is 3 ms). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to modify composing and sending a message, as disclosed by Comer, to include a send 
time interval that is less than one second, as disclosed by Sandick, in order to facilitate neighbor 
or peer protocol failure detection and expedite the detection and thereby the correction of a 
failure (Sandick; Abstract). 

9. As to Claims 6 and 32, Comer and Sandick disclose each and every limitation of Claims 
1 and 27. Sandick further discloses wherein the send time interval is less than 100 msec 
(Sandick; 7.2 Hellolnterval, discloses the Hellolnterval default value is 3 ms). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to modify composing and sending a message, as disclosed by Comer, to include a send 
time interval that is less than 100 ms, as disclosed by Sandick, in order to facilitate neighbor or 
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peer protocol failure detection and expedite the detection and thereby the correction of a failure 
(Sandick; Abstract). 

10. As to Claims 7 and 33, Comer and Sandick disclose each and every limitation of Claims 
1 and 27. Sandick further discloses wherein the aggregated message further includes a dead 
time interval (Sandick; 4.2 Parameters, discloses a PeerDeadlnterval included in the FLIP 
Advertisement). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to modify an aggregated message, as disclosed by Comer, to include a dead time 
interval, as disclosed by Sandick, in order to facilitate neighbor or peer protocol failure detection 
(Sandick; Abstract and 4.2 Parameters). 

11. As to Claims 8 and 34, Comer and Sandick disclose each and every limitation of Claims 
1 and 27. Sandick further discloses wherein the act of sending the aggregated message includes 
providing the aggregated message in an Internet protocol packet (Sandick; Abstract and 
Introduction, discloses sending a message using Internet protocol). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to modify sending an aggregated message, as disclosed by Comer, to include 
providing the message in an Internet protocol packet, as disclosed by Sandick, in order to 
facilitate neighbor or peer protocol failure detection in IP networks (Sandick; Abstract and 
Introduction). 
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12. As to Claims 9 and 35, Comer and Sandick disclose each and every limitation of claims 8 
and 34. Sandick further discloses wherein the act of sending the aggregated message towards the 
neighbor node includes setting a destination address in the Internet protocol packet to a multicast 
address associated with routers that support aggregated protocol liveness (Sandick; 4.1 Neighbor 
Discovery, 4.2 Parameters, and 4.6 Finite State Machine for Neighbor Adjacency, discloses the 
sending the message as a multicast message to a neighbor node by setting the destination address 
to a multicast address). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to modify sending an aggregated message in an IP packet, as disclosed by Comer, as 
modified by Sandick, to include setting a destination address in the Internet protocol packet to a 
multicast address, as disclosed by Sandick, in order to facilitate neighbor or peer protocol failure 
detection on a subnet (Sandick; 4.1 Neighbor Discovery, 4.2 Parameters, and 4.6 Finite State 
Machine for Neighbor Adjacency). 

13. As to Claims 10 and 36, Comer and Sandick disclose each and every limitation of Claims 
1 and 27. Comer further discloses wherein the neighbor node has at least one protocol peering 
with at least one of the at least two protocols (Comer; 15.10 BGP Functionality and Message 
Types and 15.16 BGP KEEP ALIVE Message, discloses the neighbor node has at least one 
protocol peering with one of the protocols in the first node). 

14. As to Claims 1 1 and 37, Comer and Sandick disclose each and every limitation of Claims 
1 and 27. Comer further discloses wherein the status information includes a protocol state 
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selected from a group of protocols states consisting of (A) protocol up, (B) protocol down, (C) 
protocol not reporting, and (D) protocol restarting (Comer; 15.10 BGP Functionality and 
Message Types and 15.16 BGP KEEPALIVE Message, discloses that status of the protocol is 
indicated by the ability of the node or the protocol to send messages. A peer protocol receiving 
the message indicates that the protocol state is up, and failure to receive the message indicates 
the protocol state is down). 



15. As to Claims 12 and 38, Comer discloses for use with a node, a method and elements 

(referenced hereinafter as the method) comprising: 

a) receiving, using the node, an aggregated message including 

i) for a first set of at least two different protocols of a neighbor node, status 
information for each of the protocols of the first set of the at least two different protocols 
[...] (Comer; 15.10 BGP Functionality and Message Types and 15.16 BGP KEEPALIVE 
Message, discloses receiving the BGP keepalive message including status information 
about the neighbor BGP and TCP), and 

Comer does not explicitly disclose, however Sandick discloses including the 
status information from the at least two different protocols as data within the aggregated 
message (Sandick; 4.2 Parameters and B.l Flip Advertisement Message; list of neighbor 
interfaces as data in the message that indicates the status of the interfaces) and ii) a time 
interval (Sandick; 4.2 Parameters, PeerDeadlnterval included in the FLIP 
Advertisement); and 
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It would have been obvious to one of ordinary skill in the art at the time the 
invention was made to modify status information and an aggregated message, as 
disclosed by Comer, to include explicitly indicating multiple statuses as data within the 
aggregated message and to include a dead time interval, as disclosed by Sandick, in order 
to employ known methods of explicitly indicating status in a message and to facilitate 
neighbor or peer protocol failure detection (Sandick; Abstract and 4.2 Parameters). 

Comer further discloses b) updating neighbor node protocol status information 
using the message (Comer; 15.10 BGP Functionality and Message Types and 15.16 BGP 
KEEP ALIVE Message, discloses updating TCP and BGP connection status information 
using the message). 

16. As to Claims 13 and 39, Comer and Sandick disclose each and every limitation of Claims 
12 and 38. 

Sandick further discloses wherein the act of updating neighbor node protocol status 
information includes 

i) setting, using the node, a first timer to the time interval and starting the first timer 
(Sandick; 5.3 Finite State Machine for Hello Message Exchange, discloses a setting a 
PeerDeadlnterval timer to a PeerDeadlnterval), 

Comer further discloses ii) if the first timer expires, setting, using the node, the status of 
each of the protocols of the neighbor node to down (Comer; 15.10 BGP Functionality and 
Message Types and 15.16 BGP KEEPALIVE Message, discloses setting the status of the BGP 
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and TCP protocols of the neighbor node to down when the timer expires) (Sandick; 5.3 Finite 
State Machine for Hello Message Exchange, discloses setting the status of a peer protocol of the 
neighbor node to down when the timer expires), and 

Comer further discloses iii) if a further message, sourced from the neighbor node, and 
including 

A) for a second set of at least two protocols, status information for each of the 

protocols of the second set, and 

[...] 

is received then, [. . .Jrestarting the first timer (Comer; 15.10 BGP Functionality and 
Message Types and 15.16 BGP KEEPALIVE Message, discloses restarting the timer in response 
to receiving a further keepalive). 

Comer does not explicitly disclose, however Sandick discloses B) a new time interval and 
resetting the first timer to the new time interval (Sandick; 4.2 Parameters and 5.3 Finite State 
Machine for Hello Message Exchange, discloses including a PeerDeadlnterval in the FLIP 
Advertisements, and resetting the PeerDeadlnterval timer to the time interval that is received in 
the message). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to modify a further message, as disclosed by Comer, to include a dead time interval, as 
disclosed by Sandick, in order to facilitate neighbor or peer protocol failure detection (Sandick; 
Abstract and 4.2 Parameters). 
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17. As to Claims 14 and 40, Comer and Sandick disclose each and every limitation of Claims 
13 and 39. Sandick further discloses wherein each of the time interval and the new time interval 
is less than one second (Sandick; 4.2 Parameters, 5.3 Finite State Machine for Hello Message 
Exchange, and 7.2 Hellolnterval, discloses a PeerDeadlnterval, included in the FLIP 
Advertisement, that is at least 3 times the value of the Hellolnterval, which has a default value of 
3 ms). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to modify a message, as disclosed by Comer, to include a time interval that is less than 
one second, as disclosed by Sandick, in order to facilitate neighbor or peer protocol failure 
detection and expedite the detection and thereby the correction of a failure (Sandick; Abstract 
and Introduction). 

18. As to Claims 15 and 41, Comer and Sandick disclose each and every limitation of claims 
12 and 38. Comer further discloses wherein the status information includes a protocol state 
selected from a group of protocols states consisting of (A) protocol up, (B) protocol down, (C) 
protocol not reporting, and (D) protocol restarting (Comer; 15.10 BGP Functionality and 
Message Types and 15.16 BGP KEEPALIVE Message, discloses that status of the protocol is 
indicated by the ability of the node or the protocol to send messages. A peer protocol receiving 
the message indicates that the protocol state is up, and failure to receive the message indicates 
the protocol state is down). 
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19. As to Claims 19 and 45, Comer discloses a method and a system (hereinafter referred to 
as the method) for monitoring liveness of multiple protocols, the method comprising: 

a) determining, at a first node, status information for at least two different protocols 
(Comer; 15.10 BGP Functionality and Message Types and 15.16 BGP KEEPALIVE Message, 
discloses determining at a first node status information for both BGP and TCP protocols); 

b) sending, from the first node, an aggregated message including the determined status 
information to a second node for the at least two different protocols [. . .] (Comer; 15.10 BGP 
Functionality and Message Types and 15.16 BGP KEEPALIVE Message, discloses sending a 
keepalive message indicating the status of the protocols to a second node); 

c) receiving, at the second node, the aggregated message (Comer; 15.10 BGP 
Functionality and Message Types and 15.16 BGP KEEPALIVE Message, discloses receiving the 
message at the second node); and 

d) updating, by the second node, first node protocol status information using the 
aggregated message (Comer; 15.10 BGP Functionality and Message Types and 15.16 BGP 
KEEPALIVE Message, discloses updating TCP and BGP connection status information using 
the message). 

Comer does not explicitly disclose, however Sandick discloses including the status 
information from the at least two different protocols as data within the aggregated message 
(Sandick; 4.2 Parameters and B.l Flip Advertisement Message; list of neighbor interfaces as data 
in the message that indicates the status of the interfaces). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to modify status information and an aggregated message, as disclosed by Comer, to 
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include explicitly indicating multiple statuses as data within the aggregated message, as 
disclosed by Sandick, in order to employ known methods of explicitly indicating status in a 
message. 

20. As to Claims 20 and 46, Comer and Sandick disclose each and every limitation of Claims 
19 and 45. Sandick further discloses wherein the aggregated message further includes a first 
time interval, and wherein the act of updating neighbor node protocol status information includes 

i) setting a timer to the first time interval (Sandick; 5.3 Finite State Machine for Hello 
Message Exchange, discloses a setting a PccrDcad Interval timer to a PeerDeadlnterval); 

ii) starting the timer (Sandick; 5.3 Finite State Machine for Hello Message Exchange, 
discloses a starting the PeerDeadlnterval timer); 

iii) determining whether or not a further message including protocol status information is 
received from the first node by the second node before the expiration of the timer (Sandick; 5.3 
Finite State Machine for Hello Message Exchange, discloses determining whether or not a 
further hello message including status information is received from the first node before the 
expiration of the timer); and 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to modify a message, as disclosed by Comer, to include determining whether a further 
message including protocol status information is received before the expiration of a timer, as 
disclosed by Sandick, in order to facilitate neighbor or peer protocol failure detection (Sandick; 
Abstract and Introduction). 
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Comer further discloses iv) if it is determined that a further message including protocol 
status information is not received from the first node by the second node before the expiration of 
the timer, then informing peer protocols of the second node that the at least two protocols of the 
first node are down. (Comer; 15.10 BGP Functionality and Message Types and 15.16 BGP 
KEEP ALIVE Message, discloses informing the BGP and TCP protocols of the second node that 
the BGP and TCP protocols of the first node are down when a timer expires) (Sandick; 5.3 Finite 
State Machine for Hello Message Exchange, discloses informing a peer protocol of the second 
node that the protocol of the first node is down when the timer expires). 

21. As to Claim 21, Comer and Sandick disclose each and every limitation of Claim 19. 
Comer further discloses wherein the status information includes a protocol state selected from a 
group of protocols states consisting of (A) protocol up, (B) protocol down, (C) protocol not 
reporting, and (D) protocol restarting (Comer; 15.10 BGP Functionality and Message Types and 
15.16 BGP KEEP ALIVE Message, discloses that status of the protocol is indicated by the ability 
of the node or the protocol to send messages. A peer protocol receiving the message indicates 
that the protocol state is up, and failure to receive the message indicates the protocol state is 
down). 

22. As to Claim 22, Comer discloses a machine-readable medium having stored thereon a 
machine readable aggregated message comprising: 
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a) status information, for at least two different protocols of a node, of a state of each of 
the at least two protocols (Comer; 15.10 BGP Functionality and Message Types and 15.16 BGP 
KEEP ALIVE Message, discloses sending a keepalive, with an indication of the state of the BGP 
and TCP protocols, this information is stored in the recipient node in order to determine 
connectivity and verify that the peer protocols still function); and 

Comer does not explicitly disclose, however Sandick discloses including the status 
information from the at least two different protocols as data within the aggregated message 
(Sandick; 4.2 Parameters and B. 1 Flip Advertisement Message; list of neighbor interfaces as data 
in the message that indicates the status of the interfaces) and b) a dead interval (Sandick; 4.2 
Parameters and 5.3 Finite State Machine for Hello Message Exchange, discloses including a 
PeerDeadlnterval in the message that is used by the recipient node to determine when to declare 
the peer protocol down) 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to modify status information and an aggregated message, as disclosed by Comer, to 
include explicitly indicating multiple statuses as data within the aggregated message and to 
include a dead time interval, as disclosed by Sandick, in order to employ known methods of 
explicitly indicating status in a message and to facilitate neighbor or peer protocol failure 
detection (Sandick; Abstract and 4.2 Parameters). 

23. As to Claim 23, Comer and Sandick in combination disclose each and every limitation of 
Claim 22. Comer further discloses wherein the status information indicates a protocol state 
selected from a group of protocols states consisting of (A) protocol up, (B) protocol down, (C) 



Application/Control Number: 10/775,486 Page 17 

Art Unit: 2445 

protocol not reporting, and (D) protocol restarting (Comer; 15.10 BGP Functionality and 
Message Types and 15.16 BGP KEEPALIVE Message, discloses that status of the protocol is 
indicated by the ability of the node or the protocol to send messages. A peer protocol receiving 
the message indicates that the protocol state is up, and failure to receive the message indicates 
the protocol state is down). 

24. As to Claim 24, Comer and Sandick in combination disclose each and every limitation of 
Claim 22. Sandick further discloses c) an identifier of the node (Sandick; 1.0 Terminology, 5.1 
Protocol Description, 5.2 Hello Message Contents, 5.3 Finite State Machine for Hello Message 
Exchange, discloses including the address of the node in the message that is used by the recipient 
node to determine the status of a particular peer). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to modify the data structure, as disclosed by Comer, to include an identifier of the 
node, as disclosed by Sandick, in order to facilitate neighbor or peer protocol failure detection in 
IP networks (Sandick; Abstract and Introduction). 

25. As to Claim 25, Comer and Sandick in combination disclose each and every limitation of 
Claim 24. Sandick further discloses wherein the node is a router and wherein the identifier is a 
router identifier (Sandick; 1.0 Terminology, 5.1 Protocol Description, 5.2 Hello Message 
Contents, 5.3 Finite State Machine for Hello Message Exchange, discloses including the address 
of the node, which is a router, in the message that is used by the recipient node to determine the 
status of a particular peer). 
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It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to modify the data structure, as disclosed by Comer, to include an identifier of the 
router, as disclosed by Sandick, in order to facilitate neighbor or peer protocol failure detection 
in IP networks (Sandick; Abstract and Introduction). 

26. As to Claim 26, Comer and Sandick in combination disclose each and every limitation of 
Claim 22. Sandick further discloses c) an interface index (Sandick; Appendix B.l, discloses 
including an interface index in the message that is used by the recipient node to determine the 
interface status of a peer). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to modify the data structure, as disclosed by Comer, to include an interface index, as 
disclosed by Sandick, in order to facilitate neighbor or peer protocol failure detection in IP 
networks (Sandick; Abstract and Introduction). 

27. As to Claim 47, Comer and Sandick disclose each and every limitation of claim 46. 
Comer further discloses wherein the status information includes a protocol state selected from a 
group of protocols states including at least (A) protocol up, (B) protocol down, (C) protocol not 
reporting, and (D) protocol restarting (Comer; 15.10 BGP Functionality and Message Types and 
15.16 BGP KEEP ALIVE Message, discloses that status of the protocol is indicated by the ability 
of the node or the protocol to send messages. A peer protocol receiving the message indicates 
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that the protocol state is up, and failure to receive the message indicates the protocol state is 
down). 

28. As to Claim 48, Comer and Sandick disclose each and every limitation of Claim 1 . 
Comer further discloses wherein the status information is local protocol status information 
(Comer; 15.10 BGP Functionality and Message Types and 15.16 BGP KEEPALIVE Message, 
discloses the status information is local protocol status information). 

29. As to Claim 49, Comer and Sandick disclose each and every limitation of Claim 1. 
Comer further discloses wherein the status information is local status information and wherein 
each of the at least two different protocols is bring run locally on the node (Comer; 15.10 BGP 
Functionality and Message Types and 15.16 BGP KEEPALIVE Message, discloses the status 
information is local protocol status information and each of the two different protocols is being 
run locally on the node). 

30. As to Claims 50 and 52, Comer and Sandick disclose the method of Claims 1 and 27. 
Comer further discloses wherein the status information of at least one of the at least two different 
protocols included in the aggregated message includes a protocol state set to protocol not 
reporting (Comer; 15.10 BGP Functionality and Message Types and 15.16 BGP KEEPALIVE 
Message, discloses that status of the protocol is indicated by the ability of the node or the 
protocol to send messages. A peer protocol receiving the message indicates that the protocol 
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state is up, and failure to receive the message indicates the protocol state is down, a down state 
indicates that the protocol is not reporting). 



31. Claims 18 and 44 are rejected under 35 U.S.C. 103(a) as being unpatentable over Comer 
and Sandick as applied to claims 13 and 39 above, and further in view of US Patent No. 
5,349,642 issued on September 20, 1994 to Kingdon (hereinafter "Kingdon"). 

32. As to Claims 18 and 44, Comer and Sandick in combination disclose each and every 
limitation of Claims 13 and 39. Comer and Sandick do not explicitly disclose, however Kingdon 
discloses wherein each of the aggregated message and the further message include an indication 
of a relative message age, and wherein the act of updating neighbor node protocol status 
information includes, 

iv) if the further message is received then, in addition to resetting the first timer to the new time 
interval and restarting the first timer, further 

A) determining whether the further message is younger than the message, and 

B) if it is determined that the further message is not younger than the message, then 
discarding the further message. 

(Kingdon; Figure 5, discloses determining whether the sequence number of the further received 
message is less than the sequence number of the previously received message and if this is the 
case, discarding the further message). 
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It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to modify updating neighbor node protocol status information, as disclosed by Comer, 
to include consideration of the relative message age, as disclosed by Kingdon, in order to avoid 
accepting older messages that may contain information that is no longer valid. 



33. Claims 51 and 53 are rejected under 35 U.S.C. 103(a) as being unpatentable over Comer 
and Sandick as applied to claims 1 and 27 above, and further in view of U.S. Patent No. 
7,362,700 to Frick et al. (hereinafter "Frick"). 

34. As to Claims 51 and 53, Comer and Sandick disclose the method of Claims 1 and 27. 
Comer and Sandick do not explicitly disclose, however Frick discloses wherein the status 
information of at least one of the at least two different protocols included in the aggregated 
message includes a protocol state set to protocol restarting (Frick; column 1 lines 60-63; LSA 
announces intent to perform a restart). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to modify the status information, as disclosed by Comer, to include an indication of 
restarting, as disclosed by Frick. One of ordinary skill in the art at the time the invention was 
made would have been motivated to make this combination in order to perform a hitless restart. 
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Allowable Subject Matter 

35. Claims 16, 17, 42, and 43 are objected to as being dependent upon a rejected base claim, 
but would be allowable if rewritten in independent form including all of the limitations of the 
base claim and any intervening claims. 

Conclusion 

36. THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time 
policy as set forth in 37 CFR 1.136(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within TWO 
MONTHS of the mailing date of this final action and the advisory action is not mailed until after 
the end of the THREE-MONTH shortened statutory period, then the shortened statutory period 
will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 
CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, 
however, will the statutory period for reply expire later than SIX MONTHS from the mailing 
date of this final action. 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Vivek Krishnan whose telephone number is (571) 270-5009. The 
examiner can normally be reached on Monday through Friday from 9:00 AM to 5:30 PM EST. 
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If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Glenton Burgess can be reached on (571) 276-9456. The fax phone number for the 
organization where this application or proceeding is assigned is 571-273-8300. 

Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would 
like assistance from a USPTO Customer Service Representative or access to the automated 
information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 

/V. KJ /Patrice Winder/ 

Examiner, Art Unit 2445 Primary Examiner, Art Unit 2445 



